Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-143

Text File | 1996-04-10 | 85.2 KB | 2,410 lines | [TEXT/R*ch]

C.S.M.P. Digest             Fri, 05 Apr 96       Volume 3 : Issue 143

Today's Topics:

        After 8 Choclate Strings, yum
        Control? Call to colorize floppy icon?
        DisposeMenu and popup menus
        Drawing Controls into GWorlds
        Drawing directly to the screen
        Easy PICT compression?
        Fixed point math on a PowerPC
        How to check if volume is present ie CD-ROM
        Long filenames on DOS media
        Newbie: Windows vs Dialogs
        PICT to Region
        Quick way to tell if a file is open-busy?
        Trivia:  String length limit of 200
        [Ann] Pascal Central - Updated 3-18-96  (TCL page)
        texture mapping



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet
newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and
csmp.games. It is designed for people who read news semi-regularly and
want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it. Ask your systems
administrator(s) for details. If you don't have access to news, you
may still be able to post messages to the group by using a mail server
like anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is ftp://ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Aleksander Solum)
Subject: After 8 Choclate Strings, yum
Date: 18 Mar 1996 21:25:13 GMT
Organization: Solum Forlag

CHOCOLATE STRINGS! Um,try the new program: ChockStrings with a frash
taste of Mint and of crunchy,fried bill gates. Glump. (don't take those
two lines serisously).
On with the question:
Say I have a Str255 with the info "Hi". Problem is , in that string it
could just as well say "Hello" which is so-and-so many chars bigger.
AFTER this string , which we'll name A_String , i will print " Alex.".
So "Hello" Will become "Hello Alex". (I am of course not gonna use it
for that it was just an example). I have tried this code:


short x,y;
short counter ;
Str255 A_String;
/*initlilise main function,variables toolbox and all that*/
x=20;y=30;
MoveTo ( x , y );
DrawString ( A_String ) ;
for ( counter = 0 ; counter < A_String[0];counter++)
{
  x = x + TheLenghtOfAChar;
}
MoveTo ( x , y );
x=x+TheLenghtOfAChar;
MoveTo ( x ,  y );
DrawString ("\pAlex");
<end of code>
Hwewer , that won't work cuzof ONE little thing - i don't know what to
define TheLenghtOfAChar to be. I have tried 10 ,  but i geta lotof
spacing between the characters. If i try 4 i get it too tight.. Any
help ?
BTW i'll print in 12 pointgeneva. But a function would be better. I
figure out I CAN use TeTextBox,with somting like
"rect.right=rect.right+String[0]" but it would mean a complete rewrite
of 3 pages of code. That is not very much i know,but i would like help
anyway.


TIA
-Alex
[e-mail]

PS:Mail The Answer To ME Since Mailservers crash (at least THAT is a
REASON) regularly... Somtin like that.

-Alex
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Fr. Degott)
Date: 19 Mar 1996 09:31:27 GMT
Organization: LMC-IMAG

In article <4ikkbp$[e-mail]>, [e-mail] (Aleksander
Solum) wrote:

>[cut]
> Howewer , that won't work cuzof ONE little thing - i don't know what to
> define TheLenghtOfAChar to be. I have tried 10 ,  but i geta lotof
> spacing between the characters. If i try 4 i get it too tight.. Any
> help ?
> BTW i'll print in 12 pointgeneva. But a function would be better. I
> figure out I CAN use TeTextBox,with somting like
> "rect.right=rect.right+String[0]" but it would mean a complete rewrite
> of 3 pages of code. That is not very much i know,but i would like help
> anyway.

Hi Alex,

I hope these routines will solve your problem.

FUNCTION TextWidth (textBuf: QDPtr; firstByte,byteCount: INTEGER) : INTEGER;

    TextWidth returns the width of the text stored in the arbitrary
structure in memory specified by textBuf, starting firstByte bytes into
the structure and continuing for byteCount bytes. It calculates the
width by adding the CharWidths of all the characters in the text. (See
CharWidth, above.)

FUNCTION CharWidth (ch: CHAR) : INTEGER;

    CharWidth returns the value that will be added to the pen horizontal
coordinate if the specified character is drawn. CharWidth includes the
effects of the stylistic variations set with TextFace; if you change
these after determining the character width but before actually drawing
the character, the  predetermined width may not be correct. If the
character is a space, CharWidth also includes the effect of SpaceExtra.

FUNCTION StringWidth (s: Str255 ) : INTEGER;

    StringWidth returns the width of the given text string, which it
calculates by adding the CharWidths of all the characters in the string
(see above). This value will be added to the pen horizontal coordinate
if the specified string is drawn.

HTH
Fr
_____________________________________________________________________________
Fr. Degott ([e-mail])
LogiMath, Lab. LMC-IMAG - Grenoble - France

+++++++++++++++++++++++++++

>From Eric Grayson <[e-mail]>
Date: 19 Mar 1996 23:42:28 GMT
Organization: Wolf Technical Services

Alex--

You're making a common mistake--
Not all characters are the same width!  What you want is the width of a
space in this case, so that you can get it right.  The way to do this is
to call the CharWidth function, which will give you the width, in
pixels, of the character you pass it in the current size, style and
font.

                                                                                                                                                                                            Eric



---------------------------

>From [e-mail] (Reinder Verlinde)
Subject: Control? Call to colorize floppy icon?
Date: Mon, 18 Mar 1996 16:41:24 +0100
Organization: Rijksuniversiteit Utrecht

-1- There are some applications out which enable one to give floppies
    a generic coloured icon (_without_ using any space on the floppy
    in question, i.e. without giving them a custom icon)

-2- I remember vaguely that this is done by issueing a certain Control
    call to the .Sony driver.

Question: what call does one have to make?

I have searched lots of TechNotes, qv databases, and IM manuals, but
found nothing on this subject.

TIA,

Reinder Verlinde


+++++++++++++++++++++++++++

>From Andrew Welch <[e-mail]>
Date: Tue, 19 Mar 1996 00:34:33 -0500
Organization: Ambrosia Software, Inc.

Reinder Verlinde wrote:
>
> -1- There are some applications out which enable one to give floppies
>     a generic coloured icon (_without_ using any space on the floppy
>     in question, i.e. without giving them a custom icon)
>
> -2- I remember vaguely that this is done by issueing a certain Control
>     call to the .Sony driver.
>
> Question: what call does one have to make?
>

Well I wrote a hack that did this when System 7 first came out --
because people loved the color icons, and just didn't feel complete with
the b/w icons that are on the desktop.

I did it by patching _CopyBits in the Finder and looking for the b/w
floppy icon, substituting my color pixMap for the bitmap in this case.
It's called Discolour, and I think I released the source too -- don't
remember.

+--------------------------------------------------------------+
|    Andrew Welch - Thaumaturgist - Ambrosia Software, Inc.    |
+-------------------------------+------------------------------+
|    AOL-> Keyword: Ambrosia    |  eWorld-> Shortcut: Ambrosia |
|    CIS-> GO word: Ambrosia    |  http://www.AmbrosiaSW.com/  |
+-------------------------------+------------------------------+

+++++++++++++++++++++++++++

>From [e-mail] (Bo Lindbergh)
Date: 20 Mar 1996 20:58:54 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

Just set the kHasCustomIcon bit for the floppy without providing any icon
data.  The Finder will then use icon suite -3998 from the System file.


/Bo Lindbergh

---------------------------

>From [e-mail] (Ekhaus3)
Subject: DisposeMenu and popup menus
Date: 14 Mar 1996 00:49:26 -0500
Organization: America Online, Inc. (1-800-827-6364)

hi

      just a simple question about popup menu's.   i have a modal
dialog that has a popup menu that was 'loaded' from a resource
and whose menu items were added at runtime with
'AppendMenu'.  When its time to dispose this modal dialog,
what am i responsible for with respect to this popup menu -
namely, should i call disposemenu ?  oh yeah - this is straight
C - no class library :-)

thanks
dave ekhaus

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Mon, 18 Mar 1996 16:35:34 -0800
Organization: Apple Computer, Inc.

In article <4i8c16$[e-mail]>,
[e-mail] (Ekhaus3) wrote:

  >       just a simple question about popup menu's.   i have a modal
 > dialog that has a popup menu that was 'loaded' from a resource
 > and whose menu items were added at runtime with
 > 'AppendMenu'.  When its time to dispose this modal dialog,
 > what am i responsible for with respect to this popup menu -
 > namely, should i call disposemenu ?

If you are not using the popup menu CDEF, then yes.

If you are using the popup menu CDEF and you (loaded and) inserted the
menu yourself before creating the control which uses the popup menu CDEF,
then yes.

Otherwise, no, the CDEF will do it for you.

- -

  Pete Gontier, Integer Poet, Apple Macintosh Developer Technical Support

  work      mail  <mailto:[e-mail]>
  personal  mail  <mailto:[e-mail]>
  personal  web   <http://www.ccnet.com/~gurgle>
  work      web   <http://dev.info.apple.com/dts.html>

---------------------------

>From [e-mail] (Gregory Lo)
Subject: Drawing Controls into GWorlds
Date: 23 Mar 1996 08:24:18 GMT
Organization: Queen's University

I haven't looked in the FAQ for this yet, but:

How does one go about drawing controls correctly into a GWorld?

Thanx.
GLo

+++++++++++++++++++++++++++

>From [e-mail] (Brian Zuk)
Date: Sat, 23 Mar 1996 17:02:19 -0500
Organization: Telerama Public Access Internet, Pittsburgh, PA

In article <[e-mail]>,
[e-mail] wrote:

>I haven't looked in the FAQ for this yet, but:
>
>How does one go about drawing controls correctly into a GWorld?
>
>Thanx.
>GLo

  The safest way to do this is…

- Get the PixMapHandle from the GWorld you want the control to draw into.
- Lock the GWorld's pixMap using LockPixels.
- Save the PixMapHandle of the window that owns the control.
- Call SetPortPix with the GWorld's PixMapHandle (make sure the window is
the current port first!)
- Call DrawControl
- Restore the window's original PixMapHandle by calling SetPortPix with
the saved PixMapHandle.

Brian Zuk

---------------------------

>From [e-mail] (Steve Sisak)
Subject: Drawing directly to the screen
Date: Sun, 17 Mar 1996 00:59:20 -0500
Organization: Codewell Corporation

(sorry for the re-post, but it put this in the moving th cursor thread
then realized it probably needed its own)

In article <4hnqoa$[e-mail]>, Miur <[e-mail]> wrote:

>   What sort of problems might I run into if I write directly to
> qd.screenBits.baseAddr?  I'm just concerned whether or not it will
> royally gronk someone else's computer even though it works fine on mine.
> Also, why is it that I have to multiply qd.screenBits.rowOffset by 8 to
> get the correct offset in bytes?

Don't use qd.screenBits - it assumes that the user only has one monitor -
use the Graphics Device Manager to get a PixMap for the monotir you want
to draw to or, better yet, draw to an offscreen GWorld and CopyBits it to
the screen (this is actually faster than drawing to the screen on many
systems).

In article <[e-mail]>,
[e-mail] (Mark Elliott) wrote:

> In article <[e-mail]>,
> [e-mail] (Eric A. Drumbor) wrote:
>
> >      I couldn't agree more.  I think it's hilarious (in a pathetic sort of
> > way) that Apple NOW says that there IS a compatible method for writing to
> > video memory (according to another post).  There's no reason to keep this

There has _ALWAYS_ been a compatible way of writing directly to the screen
on the MacOS.  Check out the chapters on the Graphics Device Manager
(IM-Vol 6 ch 21, IM-Imaging w/Quickdraw, ch 5)

Call GetDeviceList to get a GDHandle for the first device and
GetNextDevice to iterate through the list of montiors. You can call
GetMainDevice to get the screen with the menu bar on it, but those of us
with multiple monitors (640x280 8-bit and 1024x860 1-bit in my case) would
appreciate it if you would see if we have a montior that meets your
requirements before complaining that the main screen doesn't.  There are
other routines that let you query the capabilities of the device.

In the GDHandle is a PixMapHandle to the device's storage.  If you want to
manipulate the screen pixels directly, call LockPixels() then
GetPixMapBaseAddr() on this PixMap.  Note that this pointer is likely to
be the frame buffer and may need to be addressed in 32-bit mode - see
PixMap32Bit().

You can either mainpulate the PixMap directly or draw to them with QuickDraw.

> I am a bit sceptical about ANY games API....
> We can take shortcuts. We need speed.

One thing you may want to be _very_ aware of if you're concerned about speed:

Screen memory is marked UNCACHEABLE on a PowerPC (and some 68k machines)
this means that it is likely to be much slower to draw to the screen
directly if you do any opeations that might also read from it.  It is
often much faster to draw off screen and copy the updated pixels to the
screen.  NewGWorld/UpdateGWorld can be used to create an ofscreen buffer
with the same depth and bit alignmennt as a particular device for this
purpose.  The storage may reside on an accelerated video card and if you
use CopyBits to copy the data on screen, the copy can be accomplished by
the graphics accelerator without sending the pixels over the bus.

In short, trying to do everything yourself can be _slower_ than using the
OS, be careful and profile your code if you really care about speed.  Then
bypass the OS if you really need to.

I tend to keep the entire screen state in an offscreen GWorld, draw there
and CoypBits to the screen only the areas necessary.  In low memory
situations I draw directly to the screen, but have found this to be slower
in most cases.

-Steve


P.S. The calls to move the cursor are in the standard toolbox header
<CursorDevices.h>  I think the Cursor Device Manager is described in a
tech note - if you can't find it, send me mail and I will post its
location.

---------------------------

>From Brandon Allen <[e-mail]>
Subject: Easy PICT compression?
Date: Mon, 04 Mar 1996 17:54:59 +0000
Organization: University of Utah Computer Center

What is the easiest way to compress/decompress pict's for use in an
application?  I need to store a boatload of them and display them at
various times in my game. Are the QT routines the most convenient
way, or can I get hold of compression algorithms and do it myself?

Thanks,
Brandon Allen

+++++++++++++++++++++++++++

>From Maf Vosburgh <[e-mail]>
Date: 12 Mar 1996 17:10:47 GMT
Organization: MultiMedia Corporation plc

In article <[e-mail]> Brandon Allen,
[e-mail] writes:
>What is the easiest way to compress/decompress pict's for use in an
>application?  I need to store a boatload of them and display them at
>various times in my game. Are the QT routines the most convenient
>way, or can I get hold of compression algorithms and do it myself?
>

Use QuickTime. It is fabulous.
Compression is easy - just use an app like PictureCompressor.
If you want to do it in code, call  CompressPicture or
CompressPictureFile.

You don't need to worry about decompression - you just call DrawPicture,
and it works.

If you have a lot of images, you may want to store them in a movie.
That's a fairly common trick.


Maf

+++++++++++++++++++++++++++

>From [e-mail] (JovianSoft)
Date: 21 Mar 1996 03:12:30 -0500
Organization: America Online, Inc. (1-800-827-6364)

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>

Brandon writes:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>

Subject: Easy PICT compression?
From: Brandon Allen <[e-mail]>
Date: Tue, 05 Mar 1996 16:13:10 +0000
Message-ID: <[e-mail]>

I am wondering what the easiest way to compress/decompress PICTs is.
The game I'm writing uses lots of PICTs and without compression of
some sort, the file will be enormous. Are the QT routines the
easiest way to accomplish decent compression? Or should I try to get
ahold of an algorithm and plug out the code myself?

-Brandon Allen

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Certainly the JPEG pictures present in System 7 are the easiest to use.
However, I've noticed a few things in my own projects that you may need to
do.

First, the JPEG pictures are in millions of colors. If you decode them to
8-bit or 16-bit grafports, they'll decode *very* slowly.

Second, since they decode slowly no matter what, you may need to keep what
you can in RAM to get good performance out of them. Naturally if you use a
lot of graphics simultaneously, you won't be able to do this. So it's a
tradeoff between speed versus RAM (sound familiar?).

Third, JPEG is lossy, even on the "maximum" setting. This is usually not a
problem, but is visible under certain circumstances. My only problem with
it was with stylized text that was inside a larger screen.

Other than that, it's really simple. I use JPEG for my very large pictures
that don't move. Some of the smaller sizes I don't compress for speed
reasons.

+++++++++++++++++++++++++++

>From [e-mail] (John S. Heaney)
Date: 21 Mar 1996 11:31:48 -0800
Organization: CRL Dialup Internet Access    [phone]  [Login: guest]

>Brandon writes:
>
>I am wondering what the easiest way to compress/decompress PICTs is.
>The game I'm writing uses lots of PICTs and without compression of
>some sort, the file will be enormous. Are the QT routines the
>easiest way to accomplish decent compression? Or should I try to get
>ahold of an algorithm and plug out the code myself?

JovianSoft <[e-mail]> wrote:
>Certainly the JPEG pictures present in System 7 are the easiest to use.
>However, I've noticed a few things in my own projects that you may need to
>do.
>
>First, the JPEG pictures are in millions of colors. If you decode them to
>8-bit or 16-bit grafports, they'll decode *very* slowly.
>
>Second, since they decode slowly no matter what, you may need to keep what
>you can in RAM to get good performance out of them. Naturally if you use a
>lot of graphics simultaneously, you won't be able to do this. So it's a
>tradeoff between speed versus RAM (sound familiar?).
>
>Third, JPEG is lossy, even on the "maximum" setting. This is usually not a
>problem, but is visible under certain circumstances. My only problem with
>it was with stylized text that was inside a larger screen.
>
>Other than that, it's really simple. I use JPEG for my very large pictures
>that don't move. Some of the smaller sizes I don't compress for speed
>reasons.

You can use QuickTime compression on 8 bit images also. I've started
doing this recently. I've got 8 bit background images that are in the
200K range. I go into DeBabelizer and apply the QuickTime still
conversion. I set codec to Graphics and the quality to 100%. There's
another option in there--a popup--that I set to Color. It's a depth setting.

The result is about a 40% savings or so. It varies. I don't have to make
any changes to my code to draw the picture, as DrawPicture knows enough
to call QT to decompress it. It definitely takes longer to draw the
picture, but it's a tradeoff between that extra time and the savings in
getting the picture off the CD.

I switched back and forth between the compressed and uncompressed image
and it looks to be lossless using it this way. Furthermore, I use custom
palettes up the wazoo. Smaller graphics that appear on top of the
compressed image use the same palette. I'm not having any color mapping
problems, so the palette is obviously being preserved.

There is only one problem I have noticed and the workaround is simple.
Since I have to switch palettes all over the place, I have to fade the
screen to black, update the screen and fade up to the new colors. This
requires extensive use of the ctSeed slam so that the graphics don't all
remap to black while drawing to the faded down screen. The QT compressed
still does not work with the ctSeed slam. I can only conclude that the
graphic routines are not creating a PixMap and sending the result through
the StdBits grafProc, which is where I do one of my ctSeed slams. The
result is remapping the graphic to black, which becomes a white screen
when I fade up the colors.

The workaround is to first draw the QT compressed image into an offscreen
with the correct clut. Then I can update the screen with the offscreen
image doing a ctSeed slammed CopyBits. Since I want the background in an
offscreen anyway this isn't really a problem.

Let me clarify one thing. My original artwork is 24-bit photo realistic. I
use Debab to dither it down to 8-bit. This gives me explicit control over
the palette. Then I use the QT compression on that.

Your mileage may vary.
--
John Heaney              Time flies whether you're having fun or not.
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Dmitry Boldyrev)
Date: Wed, 20 Mar 1996 19:57:32 -0700
Organization: Xenix Demo Group

In article <4ir31e$[e-mail]>, [e-mail]
(JovianSoft) wrote:

> I am wondering what the easiest way to compress/decompress PICTs is.
> The game I'm writing uses lots of PICTs and without compression of

Well, many different ways. I personally adopted LZSS compression engine
to do fast decompression of picts. It is called LZSS Res. If you're interested,
gimme a call [phone] local at the UofU.

Demos

---------------------------

>From [e-mail] (Juri Munkki)
Subject: Fixed point math on a PowerPC
Date: 28 Feb 1996 17:57:04 GMT
Organization: Helsinki University of Technology

Supposing you had to emulate fixed point math perfectly on a PowerPC
processor, what would be the best way to do a fixed point division
operation? What would be the best way to do a multiply and divide
(using 64 bit intermediate result)?

The PowerPC architecture doesn't seem to have a division of a 64 bit
integer by a 32 bit integer. Does anyone know what method Apple uses
to emulate this 68020 instruction on the PowerPC?

The quick and dirty solution is to use the floating point divide, but
I'm worried about resolution. The results have to be exactly the same
as on a 68020.

--
Juri Munkki [e-mail]        Life is easy when polygons are cheap.
http://www.iki.fi/jmunkki           Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (Dominique Bernardi)
Date: Thu, 29 Feb 1996 10:23:33 +0100
Organization: Université Pierre & Marie Curie

In article (Dans l'article) <4h251g$[e-mail]>, [e-mail]
(Juri Munkki) wrote (écrivait) :

>Supposing you had to emulate fixed point math perfectly on a PowerPC
>processor, what would be the best way to do a fixed point division
>operation? What would be the best way to do a multiply and divide
>(using 64 bit intermediate result)?
>
>The PowerPC architecture doesn't seem to have a division of a 64 bit
>integer by a 32 bit integer. Does anyone know what method Apple uses
>to emulate this 68020 instruction on the PowerPC?
>
>The quick and dirty solution is to use the floating point divide, but
>I'm worried about resolution. The results have to be exactly the same
>as on a 68020.

I have done only the unsigned operation, because I needed those only.
You may use the following as you wish.

The global variable hiremainder contains the high 32 bits of the result
in a multiplication 32 x 32 -> 64 bits, the high 32 bits of the dividend
and the remainder in a division 64 / 32 -> 32 bit quotient and 32 bit
remainder.
The division operation *assumes* the result fits in 32 bits.
HTH.

typedef unsigned long ulong;
ulong hiremainder;

asm ulong
mulll(ulong x, ulong y)
{
      mulhwu   r5,r3,r4
      lwz      r6,hiremainder(RTOC)
      stw      r5,0(r6)
      mullw r3,r3,r4
      blr
}

asm ulong
divll(ulong x, ulong y)
{
   lwz      r5,hiremainder(RTOC)
   lwz      r0,0(r5)
   cmplwi   r0,0
   bne      @1

//  hiremainder = x % y;
//  return x/y;
   divwu    r0,r3,r4
   mullw    r4,r0,r4
   sub      r4,r3,r4
   mr       r3,r0
   stw      r4,0(r5)
   blr

@1 cmplwi   r4,0xffff
   bgt      @2

//  hiremainder = GLUE(hiremainder, HIGHWORD(x));
   rlwinm   r0,r0,16,0,15
   rlwimi   r0,r3,16,16,31
//  q1 = hiremainder / y;
//  hiremainder = GLUE(hiremainder % y, LOWWORD(x));
   divwu    r6,r0,r4
   mullw    r7,r6,r4
   sub      r0,r0,r7
   rlwimi   r3,r0,16,0,15
   mr       r0,r3
//  q2 = hiremainder / y;
//  hiremainder = hiremainder % y;
//  return GLUE(q1, q2);
   divwu    r3,r3,r4
   mullw    r7,r3,r4
   sub      r7,r0,r7
   stw      r7,0(r5)
   rlwimi   r3,r6,16,0,15
   blr

//  k = bfffo(y);
@2 cntlzw   r7,r4
//  hiremainder = (hiremainder << k) + (x >> (BITS_IN_LONG - k));
//  x <<= k; y <<= k;
   slw      r0,r0,r7
   subfic   r6,r7,32
   slw      r4,r4,r7
   srw      r8,r3,r6
   or       r0,r0,r8
   slw      r3,r3,r7
//  SPLIT(y, yh, y);
//  SPLIT(x, xh, x);
//  q1 = hiremainder / yh; if (q1 > LOWMASK) q1 = LOWMASK;
//  hiremainder -= q1 * yh;
//  aux = y * q1;
   rlwinm   r9,r4,16,16,31
   divwu    r6,r0,r9
   rlwinm   r10,r3,16,16,31
   cmplwi   r6,0xffff
   rlwinm   r4,r4,0,16,31
   rlwinm   r3,r3,0,16,31
   ble      @5
   lis      r6,1
   subi     r6,r6,1
@5 mullw    r8,r6,r9
   mullw    r12,r4,r6
   sub      r0,r0,r8

//  again:
//  SPLIT(aux, aux1, q2);
//  if (q2 > xh) aux1++;
//  if (aux1 > hiremainder)
//  {q1--; hiremainder += yh; aux -= y; goto again;}
@6 rlwinm   r11,r12,0,16,31
   cmplw    r11,r10
   rlwinm   r8,r12,16,16,31
   ble      @7
   addi     r8,r8,1
@7 cmplw    r8,r0
   ble      @8
   add      r0,r0,r9
   subi     r6,r6,1
   sub      r12,r12,r4
   b        @6

//  hiremainder = GLUE(hiremainder - aux1, LOWWORD(xh - q2));
@8  sub      r8,r0,r8
   sub      r0,r10,r11
   rlwimi   r0,r8,16,0,15
//  q2 = hiremainder / yh; if (q2 > LOWMASK) q2 = LOWMASK;
//  hiremainder -= q2 * yh;
//  aux = y * q2;
   divwu    r11,r0,r9
   cmplwi   r11,0xffff
   ble      @9
   lis      r11,1
   subi     r11,r11,1
@9 mullw    r8,r11,r9
   mullw    r12,r4,r11
   sub      r0,r0,r8

//  again2:
//  SPLIT(aux, aux1, xh);
//  if (xh > x) aux1++;
//  if (aux1 > hiremainder)
//  {q2--; hiremainder += yh; aux -= y; goto again2;}
@10   rlwinm   r10,r12,0,16,31
   cmplw    r10,r3
   rlwinm   r8,r12,16,16,31
   ble      @11
   addi     r8,r8,1
@11 cmplw    r8,r0
   ble      @12
   add      r0,r0,r9
   subi     r11,r11,1
   sub      r12,r12,r4
   b        @10

//  hiremainder = GLUE(hiremainder - aux1, LOWWORD(x - xh)) >> k;
//  return GLUE(q1, q2);
@12   sub      r4,r0,r8
   sub      r0,r3,r10
   rlwimi   r0,r4,16,0,15
   srw      r0,r0,r7
   stw      r0,0(r5)
   mr       r3,r11
   rlwimi   r3,r6,16,0,15
   blr
}
--
Dominique Bernardi, Theorie des Nombres
Universite Pierre et Marie Curie
4 place Jussieu - F75005 Paris Tel [phone]
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Kevin Armstrong)
Date: Thu, 29 Feb 1996 00:59:32 -0600
Organization: Lion Entertainment, Inc.

In article <4h251g$[e-mail]>, [e-mail] (Juri Munkki) wrote:

>Supposing you had to emulate fixed point math perfectly on a PowerPC
>processor, what would be the best way to do a fixed point division
>operation? What would be the best way to do a multiply and divide
>(using 64 bit intermediate result)?
>
>The PowerPC architecture doesn't seem to have a division of a 64 bit
>integer by a 32 bit integer. Does anyone know what method Apple uses
>to emulate this 68020 instruction on the PowerPC?
>
>The quick and dirty solution is to use the floating point divide, but
>I'm worried about resolution. The results have to be exactly the same
>as on a 68020.

I'd like to second this request.  I've done a fixed point divide in the
floating point unit without too much of a precision problem, but the
convert to and from floating point is taking up tons of time.

Maybe I should make a feature request for future PowerPC processors.  I'd
like to see 2 64-bit integer registers on the 32-bit CPUs.  I know this is
a pain, but it would make some things very nice.  Especially fixed-point
math.

For those of you thinking that I should just use the floating point unit,
I would if I wasn't getting data from the rest of the program as fixed
point.  So if there is a PowerPC integer based fixed-point solution,
please post one.

>--
>Juri Munkki [e-mail]              Life is easy when polygons are cheap.
>http://www.iki.fi/jmunkki                  Windsurfing: Faster than the wind.

Kevin Armstrong
Lion Entertainment, Inc.

+++++++++++++++++++++++++++

>From Carl R. Osterwald <[e-mail]>
Date: 29 Feb 1996 16:29:00 GMT
Organization: National Renewable Energy Laboratory

In article <[e-mail]> Dominique
Bernardi, [e-mail] writes:

>>Supposing you had to emulate fixed point math perfectly on a PowerPC
>>processor, what would be the best way to do a fixed point division
>>operation? What would be the best way to do a multiply and divide
>>(using 64 bit intermediate result)?

>>The PowerPC architecture doesn't seem to have a division of a 64 bit
>>integer by a 32 bit integer. Does anyone know what method Apple uses
>>to emulate this 68020 instruction on the PowerPC?

>>The quick and dirty solution is to use the floating point divide, but
>>I'm worried about resolution. The results have to be exactly the same
>>as on a 68020.

>I have done only the unsigned operation, because I needed those only.
>You may use the following as you wish.

Apparently Apple felt that the resolution is adequate because the new
system 7.5.3 patches include a replacement for the fixed-point math
routines that use the PowerPC FPU. According to tech note 1017,

"Rounding and pinning still matches the previous PowerPC implementation
(which is slightly different from its 68K counterpart); users of the
fixed math routines, however, should not see a difference in the
behaviour of the package, aside from faster execution."

QuickDraw uses the fixed math routines a lot, so one might expect that
the FPU solution gives the right answer.

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 1 Mar 1996 08:22:09 GMT
Organization: Helsinki University of Technology

In article <[e-mail]> [e-mail] (Kevin Armstrong) writes:
>Maybe I should make a feature request for future PowerPC processors.  I'd
>like to see 2 64-bit integer registers on the 32-bit CPUs.  I know this is
>a pain, but it would make some things very nice.  Especially fixed-point
>math.

Even if it happened, it wouldn't make any difference. The old PPC reference
guide I have here says that there is a 64/32 bit divide (as well as a
32*32->64 multiply) that is not part of the PowerPC architecture. I think
this means it is a 601 only instruction. This leaves the 603 and 604 without
the instruction, so it is not very useful unless you want to go to the
absolute maximum speed on an almost obsolete processor (just kidding for
the sake of the pun).

>For those of you thinking that I should just use the floating point unit,
>I would if I wasn't getting data from the rest of the program as fixed
>point.  So if there is a PowerPC integer based fixed-point solution,
>please post one.

The floating point solution seems viable, but a division loop might actually
be quite fast too. I don't have a PPC to test it with though. I know there
are RISC processors without any kind of hardware divide, but with a division
step instruction that enables division to be done almost as quickly as in
hardware. It's possible there might be a way to even avoid some of the
conditional branching...I would have to study the PPC instruction set more
closely and see how it could be used in this case.

At the moment I think the most likely solution is a customized fixed to
double conversion with a double precision floating point divide.

I don't have a PPC to play with, so all this is just theoretical for me.

--
Juri Munkki [e-mail]        Life is easy when polygons are cheap.
http://www.iki.fi/jmunkki           Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (Gavriel State)
Date: 1 Mar 1996 17:36:05 -0500
Organization: none

In article <4h251g$[e-mail]>, Juri Munkki <[e-mail]> wrote:
>Supposing you had to emulate fixed point math perfectly on a PowerPC
>processor, what would be the best way to do a fixed point division
>operation? What would be the best way to do a multiply and divide
>(using 64 bit intermediate result)?

Convert to double, multiply, divide, and convert back.

Floats won't have the accuracy you want, and fooling around with
mullhw and mullw (not to mention trying to divide the intermediate
64-bit result) isn't going to be any faster, and in fact will probably
be slower.  It'll also be harder to code.

--
     Gavriel State | Macintosh Software Engineer | Corel Corporation
- ------------------------------------------------------------------------
            I don't speak for Corel...at least, I usually don't.

+++++++++++++++++++++++++++

>From [e-mail] (Aaron Giles)
Date: Fri, 01 Mar 1996 23:16:18 -0800
Organization: Sirius Connections

In article <[e-mail]>, [e-mail]
(Kevin Armstrong) wrote:

> In article <4h251g$[e-mail]>, [e-mail] (Juri Munkki) wrote:
>
> >The PowerPC architecture doesn't seem to have a division of a 64 bit
> >integer by a 32 bit integer. Does anyone know what method Apple uses
> >to emulate this 68020 instruction on the PowerPC?
> >
> >The quick and dirty solution is to use the floating point divide, but
> >I'm worried about resolution. The results have to be exactly the same
> >as on a 68020.
>
> I'd like to second this request.  I've done a fixed point divide in the
> floating point unit without too much of a precision problem, but the
> convert to and from floating point is taking up tons of time.
>
> For those of you thinking that I should just use the floating point unit,
> I would if I wasn't getting data from the rest of the program as fixed
> point.  So if there is a PowerPC integer based fixed-point solution,
> please post one.

At one of the first PowerPC games kitchens (where LucasArts, Lion, and
Bungie were working on Dark Forces, Doom 2, and Marathon, respectively)
this issue came up and a number of solutions were proposed.  Eric Traut,
the man behind the DR emulator, was there and wrote a nifty bit of
hand-tweaked PPC assembly to do the 64/32-bit divide using integer math.
The code for the 32x32->64-bit multiply was trivial (3 or 4 assembly
instructions).

Then I sat down and compared results between the integer assembly code and
some quick convert-to-float-then-multiply/divide-then-convert-back macros
running on the 601 machines there.

The assembly language integer multiply (using high/low multiplies) came
out about 2x faster than the convert-to-float macros.  This was a big win.

The assembly language integer divide was a tad bit slower than the
convert-to-float macros.  It was also a lot more complicated (and hence
more error-prone).  We stuck with the macros.  I wouldn't waste my time
doing the assembly code, unless you really really want to. :-)

Hope this helps,
Aaron
--
Aaron Giles
[e-mail]
Opinions expressed herein are mine and not my employer's

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 2 Mar 1996 12:05:15 GMT
Organization: Helsinki University of Technology

In article <[e-mail]> [e-mail] (Aaron Giles) writes:
>The assembly language integer divide was a tad bit slower than the
>convert-to-float macros.  It was also a lot more complicated (and hence
>more error-prone).  We stuck with the macros.  I wouldn't waste my time
>doing the assembly code, unless you really really want to. :-)

Hmmm...well, I guess the fp solution with tweaked fixed to fp conversion
could be done with pure C.

The combined multiply/divide is easier, because no scaling needs to be done.

For the divide, I would do something like this (I haven't tested if this
works on PPC...wether it works or not depends on what happens to two
denormalized numbers that are divided. The book says they are normalized
internally, but it doesn't say if there is loss of accuracy. The code works
on a 68040 with doubles set to 8 bytes, but of course the fpu of the 040 is
different from the PPC):

Fixed    FDivC(
    Fixed    a,
    Fixed    b)
{
static    short    doubleFudgePlus[4] = { 0, 0, 0, 0 };
static    short    doubleFudgeMinus[4] = { 0x8000, 0, 0, 0 };
static    long    doubleFudgeB[2] = { 0, 0 };

    if(b < 0)
    {    doubleFudgeB[1] = -b;

        if(a < 0)
        {    *(long *)(1+doubleFudgePlus) = -a;
            return    * (double *) doubleFudgePlus /
                * (double *) doubleFudgeB;
        }
        else
        {    *(long *)(1+doubleFudgeMinus) = a;
            return    * (double *) doubleFudgeMinus /
                * (double *) doubleFudgeB;
        }
    }
    else
    {    doubleFudgeB[1] = b;

        if(a >= 0)
        {    *(long *)(1+doubleFudgePlus) = a;
            return    * (double *) doubleFudgePlus /
                * (double *) doubleFudgeB;
        }
        else
        {    *(long *)(1+doubleFudgeMinus) = -a;
            return    * (double *) doubleFudgeMinus /
                * (double *) doubleFudgeB;
        }
    }
}

The above code does not handle division by zero. It will also probably
not produce the same result as the toolbox FixDiv (or one implemented
with a true 64/32 divide), because it probably doesn't round the results
the same way when converting back to Fixed.

Last, but not least, overflow is not detected or handled.

In other words it's pretty much useless for emulating 68K code behavior.

--
Juri Munkki [e-mail]        Life is easy when polygons are cheap.
http://www.iki.fi/jmunkki           Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (RickGenter)
Date: 2 Mar 1996 21:08:08 -0500
Organization: America Online, Inc. (1-800-827-6364)

>>>
Convert to double, multiply, divide, and convert back.

Floats won't have the accuracy you want, and fooling around with
mullhw and mullw (not to mention trying to divide the intermediate
64-bit result) isn't going to be any faster, and in fact will probably
be slower.  It'll also be harder to code.
<<<

GACK! You can do a fixed point 64 by 32 bit divide using a small number of
32-by-16 bit divides (4?) and appropriate surrounding math. This is more
accurate than converting to double and back (since a double only has 53
bits of precision).

Rick Genter
Papyrus Design Group, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Davide Pasca)
Date: Tue, 05 Mar 1996 13:16:29 GMT
Organization: ValNet, Inc.

[e-mail] (Juri Munkki) wrote:

>Supposing you had to emulate fixed point math perfectly on a PowerPC
>processor, what would be the best way to do a fixed point division
>operation? What would be the best way to do a multiply and divide
>(using 64 bit intermediate result)?

Wow, this is exactly the info I was looking for !

>The PowerPC architecture doesn't seem to have a division of a 64 bit
>integer by a 32 bit integer. Does anyone know what method Apple uses
>to emulate this 68020 instruction on the PowerPC?

>The quick and dirty solution is to use the floating point divide, but
>I'm worried about resolution. The results have to be exactly the same
>as on a 68020.

Besides it is slower to convert to float and back to integer.
I've tried to track the FixMul() and FixDiv() both with MacsBug and
the CW Debugger. In the 1st case it seems to be 68K code (if I rem correctly),
in the second case the function seems to jump somewhere else where the
debugger is blind..
I definitely don't know PPC asm.

If you know something about it then, please, let me know.

Thanks !

ciaox

//=========================================================
// Davide Pasca: [e-mail] | [e-mail]
//     Homepage: http://val.net/~dpasca
//=========================================================

>--
>Juri Munkki [e-mail]        Life is easy when polygons are cheap.
>http://www.iki.fi/jmunkki           Windsurfing: Faster than the wind.

//=========================================================
// Davide Pasca: [e-mail] | [e-mail]
//     Homepage: http://val.net/~dpasca
//=========================================================


+++++++++++++++++++++++++++

>From [e-mail] (Chris Page)
Date: Thu, 07 Mar 1996 22:57:32 -0800
Organization: Don't Panic!

In article <4hk2uc$[e-mail]>, [e-mail] (Davide Pasca) wrote:

> Besides it is slower to convert to float and back to integer.

Well, I believe the next system update (to 7.5.3) will include a new,
PowerPC implementation of the Toolbox fixed-point math routines. I read
that it performs at least some of the operations by converting to
floating-point (then back). For some FP operations, the conversion time
may not be a big hit (I don't know for sure).

--
Chris Page        | Internet chain letters, advertisements and SPAMs suck...
Don't Panic!      |
[e-mail]     |                   Cut it out! :-P

+++++++++++++++++++++++++++

>From [e-mail] (Gavriel State)
Date: 11 Mar 1996 00:48:54 -0500
Organization: none

In article <4hauu8$[e-mail]>,
RickGenter <[e-mail]> wrote:
>>>>
>Convert to double, multiply, divide, and convert back.
>
>Floats won't have the accuracy you want, and fooling around with
>mullhw and mullw (not to mention trying to divide the intermediate
>64-bit result) isn't going to be any faster, and in fact will probably
>be slower.  It'll also be harder to code.
><<<
>
>GACK! You can do a fixed point 64 by 32 bit divide using a small number of
>32-by-16 bit divides (4?) and appropriate surrounding math. This is more
>accurate than converting to double and back (since a double only has 53
>bits of precision).

When you're converting back to a 32-bit value, what does it matter
that you've lost 11 bits of precision in the intermediate value?

Conversion to and from doubles takes about 3 cheap instructions each way.
Once you've got the doubles, you do two expensive instructions (the mul
and the div) and convert back.  In pure fixed point, you'll have six
expensive instructions (two muls and four divs), and your surrounding
math is likely to be more expensive than the int->fp and fp->int conversions.

On a CPU that has built-in support for long multiplies and divides, yes, it's
usually better than converting to fp.  This is just not the case on a PPC.

--
     Gavriel State | Macintosh Software Engineer | Corel Corporation
- ------------------------------------------------------------------------
            I don't speak for Corel...at least, I usually don't.

+++++++++++++++++++++++++++

>From [e-mail] (Dmitry Boldyrev)
Date: Thu, 14 Mar 1996 04:09:21 +0100
Organization: Xenix Demo Group


> On a CPU that has built-in support for long multiplies and divides, yes, it's
> usually better than converting to fp.  This is just not the case on a PPC.
>
> --
>      Gavriel State | Macintosh Software Engineer | Corel Corporation
> --------------------------------------------------------------------------
>             I don't speak for Corel...at least, I usually don't.

Actaully, I didn't notice any big differences between using integer
arithmetics and floating point arithmetics on PPC. I do realize that
PowerPC has two separate units to handle floating and integer arithmetics
but still.

Demos

+++++++++++++++++++++++++++

>From [e-mail] (Christoph Bergmann)
Date: Sun, 17 Mar 1996 20:59:48 +1000
Organization: University of Queensland

> Actaully, I didn't notice any big differences between using integer
> arithmetics and floating point arithmetics on PPC. I do realize that
> PowerPC has two separate units to handle floating and integer arithmetics
> but still.
>
> Demos

if you use numbers of any given precision, ie. all floats, or all integer,
then floating doubles _are_ the fastest by quite some on a powerpc (or at
least my 601 :). if u are using floats and often converting to integer,
consider using integer because the convert requires at least 2-3
instructions..

chrisb

+++++++++++++++++++++++++++

>From [e-mail] (Timothy A. Seufert)
Date: Sun, 17 Mar 1996 18:16:57 -0800
Organization: Evil Geniuses For A Better Tomorrow

In article <[e-mail]>,
[e-mail] (Christoph Bergmann) wrote:

>if you use numbers of any given precision, ie. all floats, or all integer,
>then floating doubles _are_ the fastest by quite some on a powerpc (or at
>least my 601 :).

Single precision FP is faster than double precision on the 601.  Its FPU
has to use two passes to do a double precision computation.  Later models,
like the 604, have no speed penalty for doubles.

+-----------------------------------------------------------+
|Tim Seufert, [e-mail] | UselessWastedSpace(tm) |
| "I never give them hell. I just tell the truth, and they  |
|  think it is hell."  -Harry S Truman                      |
+-----------------------------------------------------------+

+++++++++++++++++++++++++++

>From Lawson English <[e-mail]>
Date: 17 Mar 1996 21:20:01 -0700
Organization: Primenet [phone]

Timothy A. Seufert <[e-mail]> wrote:
[snipt]
: Single precision FP is faster than double precision on the 601.  Its FPU
: has to use two passes to do a double precision computation.  Later models,
: like the 604, have no speed penalty for doubles.


There is still the problems with loading them. While you can only load
one single or one double with a single read instruction, more singles fit
in a single cache line than do doubles, so you can process them faster.


This this wont be quite as big a deal on the 604e as it is on earlier
processors, but
even the 604e takes more  time to load from  a new cache line then from
in the cache, even if you can often make use of the data sooner than you
could with older PPCs.

--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Christoph Bergmann)
Date: Mon, 18 Mar 1996 17:54:29 +1000
Organization: University of Queensland

In article <[e-mail]>,
[e-mail] (Timothy A. Seufert) wrote:

> In article <[e-mail]>,
> [e-mail] (Christoph Bergmann) wrote:
>
> >if you use numbers of any given precision, ie. all floats, or all integer,
> >then floating doubles _are_ the fastest by quite some on a powerpc (or at
> >least my 601 :).
>
> Single precision FP is faster than double precision on the 601.  Its FPU
> has to use two passes to do a double precision computation.  Later models,
> like the 604, have no speed penalty for doubles.

maybe. my timing runs show the order from fastest to slowest to be:
doubles, floats, longs, shorts. this partially depends upon what
operations one is using, but it is the major trend.
i wont go as far as to say it _is_ this way, i havent studied it a lot :)
but this is the timing values i get and i think i saw some docs that back
that up..
anyway, as always, do some tests to see which is better in the given situ
you are using.

chris

+++++++++++++++++++++++++++

>From [e-mail] (Dmitry Boldyrev)
Date: Wed, 20 Mar 1996 20:36:43 -0700
Organization: Xenix Demo Group

In article <[e-mail]>,
[e-mail] (Christoph Bergmann) wrote:

> if you use numbers of any given precision, ie. all floats, or all integer,
> then floating doubles _are_ the fastest by quite some on a powerpc (or at
> least my 601 :). if u are using floats and often converting to integer,
> consider using integer because the convert requires at least 2-3
> instructions..
>
> chrisb

As I said, I didn't notice much difference, but I realize, it doesn't
make much sense because there are two ALU blocks for fpu and integer
arithmetics. Hmph.

Demos

---------------------------

>From [e-mail] (Brian Sweeney)
Subject: How to check if volume is present ie CD-ROM
Date: 5 Mar 1996 06:13:41 GMT
Organization: Twics Co. Ltd., Japan

I am writing an application that will be placed on the users Hard Disk and
will read data from different CD-ROMS.
How do I check that the CD-ROM is loaded ie A volume of Name "Disk1"
without trying to open a file on the disk
I tried
   err = GetVol(OldVName,&OldVRef);
   err = SetVol(TestVName,0);
   err = GetVol(OldVName2,&OldVRef2);
   .
   .
   .
   .
 etc
But it did not set to volume TestVName even though there was no error ie
OldVName2 was not equal to TestVName but still remained the same as
OldVName but err was always 0.

At best this way is sloppy and I would like a cleaner method.

+++++++++++++++++++++++++++

>From [e-mail] (Mark Allender)
Date: Thu, 07 Mar 1996 14:44:03 GMT
Organization: Parallax Software

[e-mail] (Brian Sweeney) wrote:

>How do I check that the CD-ROM is loaded ie A volume of Name "Disk1"
>without trying to open a file on the disk

Actually, there is no *real* way to tell (which is ridiculous IMHO).
There is a document that can be found on the developer CD's which will
walk you through a series of several things that you can do to
determine if a particular volume is a CDROM drive (the name --
'How to Detect a CDROM drive' or something similar to that).  I don't
have my notes or CD's handy, so I can't verify.

In short, the ways that are outlined in this document are not
foolproof for determining if a vol. is a cd or not, but they are the
best you have, and probably work in 99% of all cases.

email me if you have trouble locating it, and I'll dig it up and send
it along.
--
Mark Allender
Parallax Software
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 9 Mar 1996 01:21:13 -0500
Organization: America Online, Inc. (1-800-827-6364)

Brian Sweeney wrote:
>I am writing an application that will be placed on the users
>Hard Disk and will read data from different CD-ROMS. How do I
>check that the CD-ROM is loaded ie A volume of Name "Disk1"
>without trying to open a file on the disk

If you have access to the CD-ROMs when you build your application, you can
simply use NewAlias to create aliases to each CD and store them in your
appplication's resource fork (or another file) as 'alis' resources.

Then, when your program wants one of the CD-ROM volumes, it only has to
load the 'alis' resource for that volume and call ResolveAlias. If the
volume isn't mounted, the Alias Manager will take care of the user
interface chore of ejecting the current CD-ROM (if there are no CD-ROM
drives empty), and asking for the CD-ROM you want.

If you only want to know if the volume is mounted or not without ejecting
disks or asking for the volume, then you can call MatchAlias with the
kARMNoUI rule instead of calling ResolveAlias. With the kARMNoUI rule, the
Alias Manager doesn't try to mount the volume and returns nsvErr (-35) if
the volume is not already mounted.

- Jim Luther

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Mon, 18 Mar 1996 17:06:13 -0800
Organization: Apple Computer, Inc.

In article <4hmscu$[e-mail]>,
[e-mail] wrote:

 > ...there is no *real* way to tell (which is ridiculous IMHO).

Correct on both counts.

 > There is a document that can be found on the developer CD's which will
 > walk you through a series of several things that you can do to
 > determine if a particular volume is a CDROM drive (the name --
 > 'How to Detect a CDROM drive' or something similar to that).  I don't
 > have my notes or CD's handy, so I can't verify.

The best I was able to find is pasted at the bottom of this message.

 > In short, the ways that are outlined in this document are not
 > foolproof for determining if a vol. is a cd or not, but they are the
 > best you have, and probably work in 99% of all cases.

Once again, very true.

- ------

 > For a CD in High Sierra, ISO 9660, or audio-only formats, you can use
 > PBHGetVInfo to check for the ioVFSID (file system ID).
 >
 > High Sierra disks always have an FSID of 0x4242. ISO 9660 disks always
 > have an FSID of 0x4147. Audio CDs always have an FSID of 0x4A48.
 > You should also check for a hardware locked device by checking the ioVAtrb
 > field. The bits for this are defined on page 167 of Inside Macintosh
 > Volume IV.
 >
 > For the AppleCD SC drive, you can call the driver with a PBstatus call of
 > 97. csParam+1 contains bits corresponding to each of the eight possible
 > SCSI IDs. SCSI ID 0 is the rightmost bit. A bit is set if an AppleCD SC
 > drive exists at that SCSI ID. See the AppleCD SC Developer’s Guide,
 > available from APDA, for further details.

- -

  Pete Gontier, Integer Poet, Apple Macintosh Developer Technical Support

  work      mail  <mailto:[e-mail]>
  personal  mail  <mailto:[e-mail]>
  personal  web   <http://www.ccnet.com/~gurgle>
  work      web   <http://dev.info.apple.com/dts.html>

+++++++++++++++++++++++++++

>From [e-mail] (John C. Daub)
Date: 20 Mar 1996 04:12:17 GMT
Organization: Wish I Had More Of It

In article <[e-mail]>, [e-mail]
(Pete Gontier) wrote:

> In article <4hmscu$[e-mail]>,
> [e-mail] wrote:
>
>  > ...there is no *real* way to tell (which is ridiculous IMHO).
>
> Correct on both counts.
>
> The best I was able to find is pasted at the bottom of this message.
>
>  > In short, the ways that are outlined in this document are not
>  > foolproof for determining if a vol. is a cd or not, but they are the
>  > best you have, and probably work in 99% of all cases.
>
> Once again, very true.
>
> --------
>
>  > For a CD in High Sierra, ISO 9660, or audio-only formats, you can use
>  > PBHGetVInfo to check for the ioVFSID (file system ID).
>  >
>  > High Sierra disks always have an FSID of 0x4242. ISO 9660 disks always
>  > have an FSID of 0x4147. Audio CDs always have an FSID of 0x4A48.
>  > You should also check for a hardware locked device by checking the ioVAtrb
>  > field. The bits for this are defined on page 167 of Inside Macintosh
>  > Volume IV.
>  >
>  > For the AppleCD SC drive, you can call the driver with a PBstatus call of
>  > 97. csParam+1 contains bits corresponding to each of the eight possible
>  > SCSI IDs. SCSI ID 0 is the rightmost bit. A bit is set if an AppleCD SC
>  > drive exists at that SCSI ID. See the AppleCD SC Developer’s Guide,
>  > available from APDA, for further details.

going on the suggestion in the second paragraph, checking the hardware locked
bit is a nice simple quick way to "assume" a CD-ROM.

but there could be a "flaw" in that....what if it's a floppy disk with the
little lock tab up?  i've never tried this sort of programming checking
stuff, so i might be opening my mouth when i shouldn't be...

so, there was a little thing i saw in some network admin software that
might prove a handy helped to this "locked hardware" thing.

check the size of the volume.  this admin software considers volumes to be
CD ROMs if 1. they are locked, and 2. if over a certain number of megabytes
in size, default like 237 megs, but the user can set it to wahtever they want.

that's kinda nice at least to perhaps avoid locked 3.5" 1.44MB floppies (and
smaller).  but of course, who knows how much info and space any given CD-ROM
will have on it...maye 650megs, maybe 50.

so again, not a 100% way, but perhaps a little extension of an aforementioned
technique?

--
John C. Daub (aka Hsoi)   | <mailto:[e-mail]>
Grad Student, Lab Manager | <http://http.tamu.edu:8000/~jcd7106/>
Self-proclaimed Mac Guru  | Department of Speech Communication
Will program for food.    | Texas A&M University, USA

"Ain't it funny how that money rots your brain?"  -COC


+++++++++++++++++++++++++++

>From [e-mail]
Date: Wed, 20 Mar 1996 21:27:22 -0800
Organization: CCnet Communications (510-988-7140 guest)

In article <[e-mail]>, [e-mail]
(John C. Daub) wrote:

> In article <[e-mail]>, [e-mail]
> (Pete Gontier) wrote:
>
> > In article <4hmscu$[e-mail]>,
> > [e-mail] wrote:
> >
> >  > ...there is no *real* way to tell (which is ridiculous IMHO).
> >
> > Correct on both counts.

There is sample code on the tool chest developer CD in the Snippets
section which demonstrates many of the ways to determine if you are
talking to a CD-ROM.  For every case you can come up with, there is an
exception which proves it wrong.  You really can't tell reliably 100% of
the time.  It's strange, it's stupid, but it's true.  You get close enough
and wing it.

---------------------------

>From [e-mail]  (John Elliott)
Subject: Long filenames on DOS media
Date: 7 Mar 1996 23:39:47 GMT
Organization: Oxford University

  PC Exchange lets you use Mac filenames on DOS discs. How (precisely) are
the filenames stored on the DOS disc?
  (ie, I know they're in a hidden file, but which one, and what's the
technique to read them?)

- ------------------ http://sable.ox.ac.uk/~sjoh0132/ ---------------------
John Elliott           |BLOODNOK: "But why have you got such a long face?"
                       |SEAGOON: "Heavy dentures, Sir!"    - The Goon Show
:-------------------------------------------------------------------------)

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 12 Mar 1996 01:58:30 -0500
Organization: America Online, Inc. (1-800-827-6364)

John Elliott wrote:
>  PC Exchange lets you use Mac filenames on DOS discs. How
>(precisely) are  the filenames stored on the DOS disc?
>  (ie, I know they're in a hidden file, but which one, and
>what's the  technique to read them?)

How they are stored isn't documented and won't be because there's a really
good chance that the method will change in the future.

- Jim Luther

+++++++++++++++++++++++++++

>From [e-mail] (Mark Weinstein)
Date: 12 Mar 96 05:02:20 -0800
Organization: The Microsoft Network (msn.com)

>PC Exchange lets you use Mac filenames on DOS discs. How (precisely) are
>the filenames stored on the DOS disc?     (ie, I know they're in a hidden
>file, but which one, and what's the technique to read them?)

The name of the file PC Exchange and DOS Mounter 5.0 and up use is
called "FINDER.DAT".  You will basically find one of these files in
EVERY single subdirectory of the DOS disk.
Both programs support the identical format, which comprises a series
of 96-byte structures, each describing one file on the disk.  The
entries are NOT sorted.  Each structure or record contains the long
filename, "finfo" and "fxinfo" structures (or dinfo/dxinfo for
directories), backup/creation dates, the DOS short name equivalent,
and a bunch of other stuff.  The record layout relatively
straightforward.

The structure sequence, however, is bizarre; for a floppy disk,
starting at offset 0 of the file, five records are stored
sequentially, which gets you to offset 480.  Then the file is padded
with nothingness until offset 512, where the sixth record begins.
Basically, every 512 bytes, a new record begins.
The way the structures are used is simple; PC Exchange/DOS Mounter
find a DOS name first, then rifle through the FINDER.DAT file in that
directory looking for the matching "record" for that DOS file.  They
both use a "short name" field of the 96-byte record to determine when
a match is found.  [Thus, if you go to your DOS machine and rename
the file, it's long name will no longer show up on the mac..]  Once
it finds it, it gets the rest of the data.  If no record exists, it
is filled with default information and stored.

Also, there is an additional file on the disk, called "FILEID.DAT".
This file exists only in the root, and is responsible for managing
fileID's of files on the disk, to support the ID functions
(CreateFileIDRef(), ResolveFileIDRef(), etc).  This file is the
reason you can use alias's on DOS disks.

--
The other similar products in that class use similar techniques;
AccessPC uses "APCINFO.DAT", and older Dayna DOS Mounter versions use
a hidden "DAYNARID.SYS" store the extra Mac-specific.  But the
formats of these are a little different, but Access PC's is similar.

I am not sure how much more detail you want.  If you want more, just ask..

Hope this helped.  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro)
Date: Wed, 20 Mar 1996 16:32:20 +1200
Organization: University of Waikato

In article <4i37am$[e-mail]>, [e-mail] (Jump
Long) wrote:

>John Elliott wrote:
>>  PC Exchange lets you use Mac filenames on DOS discs. How
>>(precisely) are  the filenames stored on the DOS disc?
>>  (ie, I know they're in a hidden file, but which one, and
>>what's the  technique to read them?)
>
>How they are stored isn't documented and won't be because there's a really
>good chance that the method will change in the future.

That kind of argument can be applied to code and internal data structures,
but not to persistent data structures. Remember, whatever it's changed to
in future, it must still remain backward-compatible with the file/disk
structures that are being written today.


---------------------------

>From [e-mail] (Robert E Otto)
Subject: Newbie: Windows vs Dialogs
Date: 16 Mar 1996 22:45:19 GMT
Organization: REO Associates

I have just spent the last six weeks going thru Metowerk's "Programming
Starter Kit". Great book.  I am now just beginning to program my own
application.

I am completely uncertain about the tradeoffs between dialogs and windows.

I want to program an instrument panel. It will have sliders, buttons,
strip charts, and graphical areas.  Scrolling within a document will not
be an issue. The panel will always be the size of the current window (but
it will have a grow box). Jim's CDEFs look just like the things I need.

What issues do I need to consider? Apple's CD Audio player doesn't seem to
use anything. Sound Maching uses dialogs. Do dialogs limit you in any way?

Any help will be greatly appreciated.

--
Bob Otto
St Louis
38.612 N 90.482 W

+++++++++++++++++++++++++++

>From 'Digital Dave' Shields <[e-mail]>
Date: Sun, 17 Mar 1996 00:00:40 -0800
Organization: Vanguard Vision Studios, San Francisco, CA

Robert E Otto wrote:
>
> I have just spent the last six weeks going thru Metowerk's "Programming
> Starter Kit". Great book.  I am now just beginning to program my own
> application.
>
> I am completely uncertain about the tradeoffs between dialogs and windows.
>
> I want to program an instrument panel. It will have sliders, buttons,
> strip charts, and graphical areas.  Scrolling within a document will not
> be an issue. The panel will always be the size of the current window (but
> it will have a grow box). Jim's CDEFs look just like the things I need.
>
> What issues do I need to consider? Apple's CD Audio player doesn't seem to
> use anything. Sound Maching uses dialogs. Do dialogs limit you in any way?

The idea behind Dialogs is that they are a type of window which
originate from a template of resources. These resources are stored in
the resource fork of your application. Use ResEdit to open a copy of any
application, and look at the DLOG and corresponding DITL resources which
share the same ID number. See how they are described.

Once you use ResEdit or ReSourcer to create these DLOG and DITL types of
resources, you can set up a Dialog Window and refer to its controls,
called Dialog Items, by ID number. Updates for the controls are managed
by the Dialog manager.

The alternative, using regular Windows, is that you have to keep and
manage the handles to all Controls which go on it. You can create
controls for windows, and manage their updating yourself. But if you
have a lot of controls (more than just scrollBars) you would probably be
better using Dialogs.

There are two kinds of Dialogs--modal (which do not allow the user to
continue until he has dismissed the Dialog Window), and modeless--which
allow the user to click outside the Dialog and return to it like any
other kind of Window. The purpose of Modal Dialogs is to display
something the user must confirm seeing or make a choice about. You don't
want him wandering off--this item needs attention now...

So, with modal dialogs, there is a special routine that keeps returning
the 'DITL' item which gets hit upon by the user. It is called
"ModalDialog()". Using it within a do loop, keeps the Dialog from
getting dismissed, until the correct item is hit (which you define.)

Another sub-category of Dialog is called an Alert. Alerts are Dialogs
which have the ModalDialog routine built into them. You can use 'ALRT'
resources and corresponding 'DITL' resources to define a Dialog Box
which posts a simple cautionary or warning message (or even a diagnostic
one.)

Happy Windows programming...ooops...Forgive me...I mean happy coding
windows and dialogs on your Mac...:-)

--Dave

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Mon, 18 Mar 1996 15:25:51 -0800
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Robert E Otto) wrote:

 > Do dialogs limit you in any way?

Yes. In plenty of ways.

The example that comes to mind is text editing. editText items are not
very versatile and very difficult to customize. You can use an 'ictb'
resource to specify font, size, style, etc. info for an individual
editText item as long as you're happy with the entire editText item being
the same all the way through and not changing. And it's not easy to edit
large chunks of text or add scroll bars to editText items.

Most all of the other dialog components have roughly equivalent limitations.

However, if you plan to do most of the interesting parts of your interface
through custom controls, you might be OK.

- -

  Pete Gontier, Integer Poet, Apple Macintosh Developer Technical Support

  work      mail  <mailto:[e-mail]>
  personal  mail  <mailto:[e-mail]>
  personal  web   <http://www.ccnet.com/~gurgle>
  work      web   <http://dev.info.apple.com/dts.html>

---------------------------

>From [e-mail] (Ed van Zon - FD, Min.LNV)
Subject: PICT to Region
Date: 4 Mar 96 09:50:25 +0100
Organization: TFDL Wageningen, The Netherlands

I want to get the region exactly enclosing a given PICT.

How I tried it:
  OpenRgn
  DrawPict
  CloseRgn
Now the region is considerable smaller than the PICT.
I tried the kludge:
  InsetRgn( rgn, -1, -1)
Now the region _almost_ encloses the PICT exactly; there are just
a few pixels the region includes outside the PICTs outline. But this still
isn't good enough for me.

The PICT was authored using SuperPaint; it's a polygon with linewidth 2
(it has the form of a hexagon, but I'm _not_ using the hexagon-shape tool).
After pasting this into the resource fork, it draws correctly on screen.
So why is it that drawing it into a region, the region is just too small?

Anybody got a suggestion, or even a solution to what I want?
I would appreciate it very much if you share it with me.

Ed van Zon
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Yennie)
Date: 4 Mar 1996 15:42:06 -0500
Organization: America Online, Inc. (1-800-827-6364)

If your PICT is a simple shape, I would just draw it manually:
OpenRgn
MoveTo x,y
LineTo x1,y1
MoveTo x1,y1
LineTo x2,y2
......
LineTo x,y
CloseRgn

One other suggestion: when drawing the PICT (I assume you are using
DrawPicture which takes a PICT handle and a rectangle as parameters), are
you sure you're using the correct rectangle? I believe you should use the
rectangle pictHandle@@.pictBounds (that field name might not be right, but
its something like that).

Good luck!

+++++++++++++++++++++++++++

>From [e-mail] (Job Oostindie)
Date: Tue, 5 Mar 1996 07:07:38 GMT
Organization: Multihouse Automatisering b.v.

Ed van Zon - FD, Min.LNV ([e-mail]) wrote:
: I want to get the region exactly enclosing a given PICT.

: How I tried it:
:   OpenRgn
:   DrawPict
:   CloseRgn
: Now the region is considerable smaller than the PICT.
: I tried the kludge:
:   InsetRgn( rgn, -1, -1)
: Now the region _almost_ encloses the PICT exactly; there are just
: a few pixels the region includes outside the PICTs outline. But this still
: isn't good enough for me.

The problem may be the pensize. The pensize expands any drawn object with
xPenSize pixels to the right and yPenSize pixels downwards.
So, when you used pensize( 2, 2 ) to draw the picture, I think you need to
InsetRgn( rgn, -1, -1 ) and afterwards OffsetRgn( rgn, -1, -1)
Hope this helps.

+------------------------------------------------------------------------+
|  Job Oostindie                    Information Engineer                 |
|  Email: [e-mail]                 Multihouse Automatisering B.V.       |
|  Phone: [phone]           Holland                              |
|  Fax:   [phone]                                                |
+------------------------------------------------------------------------+

+++++++++++++++++++++++++++

>From [e-mail] (Martin-Gilles Lavoie)
Date: Tue, 05 Mar 1996 08:30:56 -0500
Organization: Groupimage, inc.

In article <1996Mar4.095025.378@ns2>, [e-mail] wrote:

> I want to get the region exactly enclosing a given PICT.
>
> How I tried it:
>   OpenRgn
>   DrawPict
>   CloseRgn
> Now the region is considerable smaller than the PICT.
> I tried the kludge:
>   InsetRgn( rgn, -1, -1)
> Now the region _almost_ encloses the PICT exactly; there are just
> a few pixels the region includes outside the PICTs outline. But this still
> isn't good enough for me.
>
> The PICT was authored using SuperPaint; it's a polygon with linewidth 2
> (it has the form of a hexagon, but I'm _not_ using the hexagon-shape tool).
> After pasting this into the resource fork, it draws correctly on screen.
> So why is it that drawing it into a region, the region is just too small?
>
> Anybody got a suggestion, or even a solution to what I want?
> I would appreciate it very much if you share it with me.
>
> Ed van Zon
> [e-mail]

Unfortunatelly, regions dont take into account the thickness of lines when
they are being constructed using PenSize(>1,>1).  A workaround is to use
the BitmapToRegion() function (described in QuickDraw chapters of Inside
Mac).

This function converts a bitmap or pixmap into a region.  However, it's
not perfect.

--
Martin-Gilles Lavoie

[CYRNFR QB ABG ZVK BE BGUREJVFR NYGRE GUR OVGF VA GUVF ZRFFNTR.]

+++++++++++++++++++++++++++

>From [e-mail] (Ed van Zon)
Date: Wed, 06 Mar 1996 19:55:19 +0100
Organization: Solar Software

In article <mouser-0503960830560001@204.191.6.170>, [e-mail]
(Martin-Gilles Lavoie) wrote:

> In article <1996Mar4.095025.378@ns2>, [e-mail] wrote:
>
> > I want to get the region exactly enclosing a given PICT.
>
> Unfortunatelly, regions dont take into account the thickness of lines when
> they are being constructed using PenSize(>1,>1).  A workaround is to use
> the BitmapToRegion() function (described in QuickDraw chapters of Inside
> Mac).
>
> This function converts a bitmap or pixmap into a region.  However, it's
> not perfect.
>
> --
> Martin-Gilles Lavoie
>
> [CYRNFR QB ABG ZVK BE BGUREJVFR NYGRE GUR OVGF VA GUVF ZRFFNTR.]

Thanks for the pointer to BitmapToRegion(). It indeed solved my problem.

Ed.

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Mon, 18 Mar 1996 16:03:49 -0800
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Job Oostindie) wrote:

 > Ed van Zon - FD, Min.LNV ([e-mail]) wrote:
 > : I want to get the region exactly enclosing a given PICT.
 >
 > : How I tried it:
 > :   OpenRgn
 > :   DrawPict
 > :   CloseRgn
 > : Now the region is considerable smaller than the PICT.

I don't think DrawPicture is going to do what you want.

Pictures can have embedded region and polygon operations. Some of these
are likely to require calls to OpenRgn or OpenPoly. On page 3-88 of Inside
Mac: Imaging with QuickDraw, we see: "Do not call OpenRgn while another
region or polygon is open." This is due to the way a temporary storage
handle is allocated in the current GrafPort. There's only one handle per
GrafPort.

Also: Pictures can be large. On page 3-88 of Inside Mac: Imaging with
QuickDraw, we see: "Regions are limited to 32Kb (...or...) 64Kb..."

You might try HidePen and filtering some of the QuickDraw bottlenecks to
keep track of the limits of drawing. You'll probably want to look up the
calls SetStdProcs and SetStdCProcs in the aforementioned volumes for more
info.

- -

  Pete Gontier, Integer Poet, Apple Macintosh Developer Technical Support

  work      mail  <mailto:[e-mail]>
  personal  mail  <mailto:[e-mail]>
  personal  web   <http://www.ccnet.com/~gurgle>
  work      web   <http://dev.info.apple.com/dts.html>

+++++++++++++++++++++++++++

>From [e-mail] (Jerome Jahnke)
Date: Wed, 20 Mar 1996 04:08:24 GMT
Organization: BSD Academic Computing

In article <[e-mail]>, [e-mail]
(Pete Gontier) wrote:

> In article <[e-mail]>,
> [e-mail] (Job Oostindie) wrote:
>
>  > Ed van Zon - FD, Min.LNV ([e-mail]) wrote:
>  > : I want to get the region exactly enclosing a given PICT.
>  >
>  > : How I tried it:
>  > :   OpenRgn
>  > :   DrawPict
>  > :   CloseRgn
>  > : Now the region is considerable smaller than the PICT.
>
>
> You might try HidePen and filtering some of the QuickDraw bottlenecks to
> keep track of the limits of drawing. You'll probably want to look up the
> calls SetStdProcs and SetStdCProcs in the aforementioned volumes for more
> info.

If he is looking for an outline, and the background of his picture is
white he might try opening the picture converting it to a black and white
image, and then doing a BitMapToRegion.

We do this to get outlines for pictures we are dragging around. We on
occasion perform one more step that is making sure the picture is
displayed as an 8 bit image we turn all colors but white in the color
table to black before we convert it to a 1 bit image. This gives us a nice
outline we can use to convert to a region which gives us a nice outline
for dragging. Although we are going to look into this transparent drag
mode next.

Jer,

--
Jerome Jahnke
BSD Academic Computing
University of Chicago
[e-mail]


---------------------------

>From [e-mail] (Stephen Zagerman)
Subject: Quick way to tell if a file is open-busy?
Date: Wed, 20 Mar 1996 17:00:12 -0800
Organization: Stephen Zagerman Consulting

I'm writing an app (Client) that uses aevt's to tell another app (Server)
to take action that causes a new file to be created and written to. The
Client needs to then examine the file that the Server created, but should
not access it until the Server is done writing to it and has closed it.

This seems simple, but I can find any toolbox calls that let me know
whether a file is open or busy... Anyone know how to do it?

Thanks,

Steve

+++++++++++++++++++++++++++

>From [e-mail] (Ken Victor)
Date: Wed, 20 Mar 1996 19:50:25 -0800
Organization: Victor Consultin

In article <[e-mail]>, [e-mail]
(Stephen Zagerman) wrote:

>This seems simple, but I can find any toolbox calls that let me know
>whether a file is open or busy... Anyone know how to do it?


PBGetCatInfo will return as part of the param block a refnum if the file
is already open, and the flags will indicate whether the resource/data
forks are open.

ken


+++++++++++++++++++++++++++

>From [e-mail] (Greg Branche)
Date: Tue, 26 Mar 1996 12:50:23 -0800
Organization: General Magic

In article <[e-mail]>, [e-mail]
(Stephen Zagerman) wrote:

>I'm writing an app (Client) that uses aevt's to tell another app (Server)
>to take action that causes a new file to be created and written to. The
>Client needs to then examine the file that the Server created, but should
>not access it until the Server is done writing to it and has closed it.
>
>This seems simple, but I can find any toolbox calls that let me know
>whether a file is open or busy... Anyone know how to do it?
>

Take a look at PBGetCatInfo.  The ioFlAttrib field of the parameter block
has bits defined that'll let you know if the file is open, and
specifically which fork (or both forks, for that matter).

Greg Branche
Magic Cap Entomologist
General Magic, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Dave M Brosius)
Date: 23 Mar 1996 08:20:12 GMT
Organization: Chester County Internet Services, Inc.

In article <[e-mail]>, [e-mail]
(Stephen Zagerman) wrote:

> I'm writing an app (Client) that uses aevt's to tell another app (Server)
> to take action that causes a new file to be created and written to. The
> Client needs to then examine the file that the Server created, but should
> not access it until the Server is done writing to it and has closed it.
>
> This seems simple, but I can find any toolbox calls that let me know
> whether a file is open or busy... Anyone know how to do it?
>
> Thanks,
>
> Steve

PBGetCatInfo will return in ioFRefNum, an refnum of the first open access
path. If this value is 0, the file is closed.

--
Please reply via email as well
dave [e-mail]
visit me at http://www.chesco.com/~dbrosius

---------------------------

>From [e-mail] (John W. Baxter)
Subject: Trivia:  String length limit of 200
Date: 10 Mar 1996 23:32:05 GMT
Organization: Internet for the Olympic Peninsula

What string defined in the Mac Toolbox is limited to 200 characters?
    --John

--
  The month after next is May.
John W. Baxter    Port Ludlow, WA, USA     [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 16 Mar 1996 02:00:21 -0500
Organization: America Online, Inc. (1-800-827-6364)

John W. Baxter asked:
>What string defined in the Mac Toolbox is limited to 200
>characters?

Besides the comment string you pass to PBDTSetComment (my last answer), I
thought of another string that is about that length: The server message
string returned by the AppleTalk Filing Protocol in response to
afpGetSrvrMsg requests is a Str199 (200 bytes including the length
character).

By the way, nobody has taken a stab at the trivia reply question I posted:

>Now, here's another trivia question: What file system's Desktop
>Manager implementation returns 255 character comment strings to
>PBDTGetComment?

- Jim Luther

[e-mail]
<http://members.aol.com/JumpLong/>

---------------------------

>From [e-mail] (Bill Catambay)
Subject: [Ann] Pascal Central - Updated 3-18-96  (TCL page)
Date: Mon, 18 Mar 1996 09:37:19 -0800
Organization: MacPascal


To all Pascal programmers:

Check out the Pascal Central web site:

http://www.webcom.com/icog/polymorphic/pascal.html

The latest article posted to Pascal Central is "TCL Pascal LIVES!!!", a
collection of TCL source code tidbits for Pascal TCL programmers.  Check
out the page, and if you have any suggestions or additions to it, please
contact the editor of the page.

Pascal Central is a collection of Pascal-related content all in one
location to make it easier for the many Pascal developers out there to
cope in a world dominated by C and C++.

If you have any pascal-related articles, documented source code or book
reviews you think would be of benefit to the Pascal community, let me
know.  Pascal Central is now going through adolescence, and I'm always
looking to the Pascal community to help mature its content.

Cheers,
Bill

_____________________________________________________________________
Bill Catambay
Pascal Programmer on Macintosh and Open VMS

              />
             //   The purpose of software engineering
     (//////[O]>=========================================-
             \\    is to manage complexity, not to create it.
              \>

____________________________________________________________________


---------------------------

>From [e-mail] (Jared Buttles)
Subject: texture mapping
Date: Wed, 20 Mar 1996 11:13:54 -0800
Organization: University of Idaho, Moscow, Idaho

Does anyone out there know where I can find decent texture mapping
algorithms? Books, source, ftp sites, etc. Anything would be appreciated.
Thanx in advance.

+++++++++++++++++++++++++++

>From [e-mail] (Eric A. Drumbor)
Date: Thu, 21 Mar 1996 06:41:08 -0700
Organization: BW Software

In article <[e-mail]>,
[e-mail] (Jared Buttles) wrote:

> Does anyone out there know where I can find decent texture mapping
> algorithms? Books, source, ftp sites, etc. Anything would be appreciated.
> Thanx in advance.

     Perspective or affine?  I assume you mean perspective, which is what
you want if you are looking for texture mapping that won't become
distorted when your viewer/camera/psycho-killer/ship/whatever is close to
the textured polygon.

     If you're completely new to texture mapping, you may want to try out
affine just to get an understanding of how perspective will work (to some
degree).  Michael Abrash's "Zen of Graphics Programming" describes affine
texture mapping fairly well, even though it's a PC book.  I'm sure there
are also some examples of affine on the x2ftp site, but I can't confirm
that.  After you have affine down, move on to perspective correct texture
mapping.  It's slower than affine, but visually speaking it's much better.

     There are books out there that describe texture mapping (I believe
it's Wolhberg's "Digital Image Warping") but personally I like Chris
Hecker's articles in Game Developer magazine.  They're clear, and so far
the code has been easily usable on the Mac (although I wrote my own
version in C).  You'll need to order back issues of Game Developer (BTW
they're bi-monthly):  April/May, June/July, Aug/Sept, and Dec/Jan.

     Obviously, Kevin Tieskoetter's upcoming book should be really helpful too.

     Texture mapping (perspective correct) may seem difficult at first,
but once you have the basics down it's really quite easy to work with, and
optimize.

--
"I think the term rhymes with clucking bell..." - Black Adder
Eric A. Drumbor
BW Software              <http://ra.nilenet.com/~ericd/>
[e-mail]
For info on BW Software's upcoming 3D game, look at our web page:
http://ra.nilenet.com/~ericd/Aequator.html

+++++++++++++++++++++++++++

>From [e-mail] (Kevin Armstrong)
Date: Thu, 21 Mar 1996 12:55:10 -0600
Organization: Lion Entertainment, Inc.

In article <[e-mail]>,
[e-mail] (Jared Buttles) wrote:

>Does anyone out there know where I can find decent texture mapping
>algorithms? Books, source, ftp sites, etc. Anything would be appreciated.
>Thanx in advance.

Michael Abrash's book Zen of Graphics Programming has a good Texture
Mapper in the back.  It doesn't do perspective, but it isn't too hard to
modify it to get it to do it.  And you'll probably want to optimize it a
bunch, but it is a good place to start.

The only problem from a Mac point of view is that most of the book is
about PC relevant stuff.  Lots of info on VGA and x86 assembly.

Kevin Armstrong
Lion Entertainment, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Jon Blossom)
Date: Fri, 22 Mar 1996 18:27:44 GMT
Organization: (none)

[e-mail] (Jared Buttles) wrote:

>Does anyone out there know where I can find decent texture mapping
>algorithms? Books, source, ftp sites, etc. Anything would be appreciated.
>Thanx in advance.

Chris Hecker wrote an excellent series about perspective texture
mapping in Game Developer magazine.

Check out ftp://ftp.mfi.com/pub/gamedev/src, and/or
http://www.mfi.com/gdmag.

I think he's planning on making it available on his homepage, which
may or may not be up yet. http://www.nwlink.com/~checker.

-Jon Blossom
[e-mail]



---------------------------

End of C.S.M.P. Digest
**********************